Aplicaciones de software como servicio (página 2)

El modelo de software brindado como servicio introduce algunos aspectos desconocidos a la arquitectura que son inherentes al modelo y otros que surgen de conocidos modelos, como utility computing, o estilos de arquitectura como SOA y se manifiestan en otros dominios. Sin embargo es difícil encontrar la definición de estos atributos y su taxonomía en su conjunto. Al ser un modelo relativamente nuevo, el mercado está enfocado más en la demanda que en la oferta. Esto puede resultar en una arquitectura inapropiada o incluso en falta de capacidad de IT para alinearse con los objetivos de negocio.

Por otra parte, no solo el modelo es relativamente nuevo, sino que la infraestructura disponible como el hardware, almacenamiento y conectividad avanzó mucho en los últimos años. Gracias a estos avances proliferan nuevas formas de diseñar, desplegar y mantener soluciones que antes no eran técnicamente posibles.

Si bien existen implementaciones de software brindado como servicio en diferentes plataformas, todas estas son de código cerrado ya que brindan un servicio pago y los diseños, algoritmos, patrones y arquitecturas permanecen bajo su dominio.

En resumen, el problema se define de la siguiente manera:

• No existen herramientas que permitan hacer una evaluación y un plan de ejecución para el ciclo de vida de aplicaciones de software ofrecido como servicio

• No existe un Cuerpo de Conocimiento (BOK) que identifique y defina los atributos de software ofrecido como servicio

• No existe un Cuerpo de Conocimiento (BOK) que identifique y defina las arquitecturas, diseños, tecnologías y patrones asociados a esos atributos

• Si existen soluciones que resuelven estas problemáticas pero son propietarias

Por lo tanto, el objetivo es:

• Identificar, definir y categorizar los atributos, capacidades y desafíos técnicos del software brindado como servicio y a partir de estos plantear alternativas de solución, patrones de diseño, estilos de arquitecturas y tecnologías con el fin de proveer un marco para evaluar, planificar y diseñar proyectos de software brindado como servicio basados en un lenguaje común

Esta tesis no pretende:

• Brindar una única solución que se adapte a todas las necesidades y objetivos de negocios relacionados con Software como Servicio

• Crear nuevos lenguajes de programación o plataformas. Por el contrario, el trabajo estará basado sobre plataformas, especificaciones, estándares y lenguajes existentes

• Abordar las problemáticas de negocios asociadas a las diferentes alternativas planteadas

• Incluir en el análisis aspectos relacionados con el proceso de desarrollo de software ni sus correspondientes metodologías

Solución propuesta

La solución incluye definir las características de una aplicación de Software como Servicio, definir una taxonomía y por último darle un tratamiento a cada una de ellas. Este proceso se realizará bajo un método llamado Feature Modeling , muy utilizado en Software Product Line Engineering (SPLE) [Kang K., 1990]. El objetivo es analizar el dominio de aplicaciones brindadas como servicio (ver 7.1 Análisis de Dominio) que se puede ver como una familia de productos y ensayar un modelo de características (ver 7.2 Modelo de Características) que cubra el dominio holísticamente.

Desarrollo de software generativo Un concepto clave en el desarrollo de software generativo [Overview of Generative Software Development, 2005] es el mapeo entre el espacio del problema (problem space) y el espacio de la solución (solution space). El espacio del problema es un conjunto de abstracciones específicas del dominio que pueden ser usadas para expresar las necesidades para ese dominio. Por ejemplo, en un sistema de e-commerce se podría especificar los diferentes métodos de pago. El espacio de solución por otro lado consiste en abstracciones orientadas a la implementación que pueden ser instanciadas para crear soluciones a las especificaciones de dominio expresadas en el espacio del problema. Por ejemplo, los métodos de pago se podrían implementar como llamadas a servicios web como PayPal o a otro Gateway de pagos en caso de utilizar tarjeta de crédito. Si el método de pago es con cupones de descuento o puntos se utiliza una base de datos con un mecanismo que maneja los cupones. El mapeo entre estos dos espacios se traduce en la realización de una instancia específica de la familia de productos potenciales y una técnica para definir ese mapeo es utilizando un modelo de características.

Figura 12 – Mapeo del espacio del problema al espacio de solución [Overview of Generative Software Development, 2005] Durante el desarrollo de esta tesis se utilizó esta separación con el objetivo de definir el problema y desacoplarlo de la o las posibles soluciones.

Modelado de características El modelado de características es un método y una notación para representar características comunes y variables de los sistemas dentro de una familia de sistemas [Overview of Generative Software Development, 2005]. Este modelo, permite en las etapas tempranas del desarrollo de familias de productos definir el alcance del dominio evaluando e identificando las características importantes del dominio. Utilizando este método se puede priorizar y diseñar una arquitectura tomando las características de a una por vez, dejando registradas las decisiones tomadas en las etapas posteriores.

Figura 13 – Ejemplo de un diagrama de características [Overview of Generative Software Development, 2005] El primer paso hacia el modelado de características es el análisis del dominio [Concepts and Guidelines of Feature Modeling for Product Line Software Engineering, 2002]. Sin un entendimiento total del dominio este no puede ser caracterizado y modelado.

• Análisis de Dominio

Software como Servicio es un dominio emergente e inmaduro. En este contexto diferentes terminologías con el mismo significado pueden ser utilizadas en diferentes contextos. Estandarizar los conceptos del dominio es una actividad esencial para el modelado de características. Si esto no se realiza, las diferentes concepciones del dominio podrían causar confusión en etapas posteriores [Concepts and Guidelines of Feature Modeling for Product Line Software Engineering, 2002]. La caracterización de los conceptos se basó en las siguientes actividades:

• Análisis de la industria

• Participación en proyectos de Software como Servicio

• Exploración de papers de la industria, de investigación académica e investigación de mercado

• Interacción con expertos

El siguiente diagrama sintetiza el análisis realizado de las características relacionadas con software brindado como servicio.

Figura 14 – Análisis del dominio de Software como Servicio Software como Servicio se forma a partir de diferentes orígenes como muestra la figura anterior. En el último tiempo el término fue mutando y hoy también se conoce como parte de un concepto más extenso "Cloud Computing". Sin embargo, a la fecha, el término Software como Servicio sigue siendo significativo e identifica al modelo unívocamente. En las secciones subsiguientes se definirá cada una de las ramas del diagrama y las características enunciadas.

• SaaS y Utility Computing

La primera rama a analizar es utility computing. Según Wikipedia la siguiente es la definición de utility computing:

"Utility computing se define como el suministro de recursos computacionales, como puede ser el procesamiento y almacenamiento, como un servicio medido similar a las utilidades públicas tradicionales (como la electricidad, el agua, el gas natural o el teléfono). Este sistema tiene la ventaja de tener un costo nulo o muy bajo para adquirir hardware; en cambio, los recursos computacionales son esencialmente alquilados. Los clientes que realizan procesamiento de datos a gran escala o que están frente a un pico de demanda, también pueden evitar los atrasos que resultarían de adquirir y ensamblar físicamente una gran cantidad de computadoras."7

Este concepto no es nuevo, sino que data de la época en que IBM y otros proveedores de mainframe ofrecían procesamiento y almacenamiento, también conocido como time-sharing, a bancos y grandes corporaciones desde sus datacenters. Los sistemas operativos del mainframe evolucionaron de acuerdo al modelo de negocios que se había creado introduciendo capacidades de seguridad y medición y quota por usuario. Años más tarde, con la llegada de la computadora personal el modelo de negocios había cambiado y las compañías pudieron afrontar el gasto de tener sus propios datacenters.

Volvió a resurgir este modelo, esta vez empujado por la ciencia y la necesidad de mercados específicos como el financiero. La idea de utilizar todas las PC del mundo para resolver problemas que requerían un gran poder de procesamiento se popularizó a finales de los 90 con programas como SETI@home. El termino grid computing nació como una metáfora relacionada con lograr que el poder de procesamiento de las computadoras sea tan accesible como una red eléctrica (power grid).

En el año 2006 la compañía 3tera anunció su servicio AppLogic mediante el cual brinda pool de recursos virtuailizados y almacenamiento. Ese mismo año Amazon lanzó Amazon EC2 (Elastic Computing Cloud). Ambos servicios están construidos sobre el software de virtualización Xen y corren sobre distribuciones Linux. El mercado bautizó este tipo de servicios como utility computing.

Las empresas que desean construir una aplicación SaaS ven a los proveedores de utility computing como una excelente alternativa ya que reduce costos operativos, de hardware y hasta infraestructura edilicia. Asimismo proveen recursos infinitos, fácilmente aprovisionados, brindando una alta disponibilidad y escalabilidad.

Basado en la definición mencionada anteriormente, utility computing lleva el concepto de servicio o utilidad al campo de recursos computacionales, más específicamente ligados al hardware (almacenamiento, poder de cómputo y red). Incluye en la definición la palabra "medido", "alquilado" y "costo bajo". Por lo tanto debe existir una arquitectura para optimizar los recursos y albergar a múltiples clientes (multi tenancy) logrando un costo bajo (monetización) y una economía de escala. El servicio debe ser medido para ser cobrado por lo tanto requiere una actividad de monitoreo y medición y el establecimiento de un acuerdo de nivel de servicio (manejo de SLA). Por último, enuncia picos de demanda y atrasos en adquirir y ensamblar computadoras, lo que está relacionado con escalabilidad a demanda, manejo de recursos y cuotas y aprovisionamiento automático para minimizar los tiempos de alta y mantenimiento del servicio.

Entre las compañías más conocidas que trabajan con este modelo se encuentran Amazon (Amazon Web Services), GoGrid, Mosso y otras.

Características resumidas

• Recursos computacionales provistos a demanda

• Disco

• CPU

• Red

• Medición del uso y cuotas

• Acuerdo de nivel de servicio

• Automatización del proceso de aprovisionamiento de los recursos

• Multi tenancy y monetización

• SaaS y Platform as a Service

Continuando con el análisis, la siguiente es la definición de platform as a service:

"El modelo de platform as a service integra todas las facilidades necesarias para soportar el ciclo de vida de punta a punta para la construcción y la distribución de aplicaciones web y servicios enteramente disponibles via internet. PaaS ofrece facilidades para el diseño de aplicaciones, desarrollo de aplicaciones, testing, despliegue y alojamiento. "8

Como indica la definición, Platform as a Service engloba al conjunto de soluciones que brinand una plataforma para desarrollar. A diferencia del modelo tradicional donde el desarrollo y el despliegue se realizan en ambientes controlados y en infraestructura propia, tanto el desarrollo como el despliegue se trasladan a internet. Para eso brindan herramientas de desarrollo y herramientas de despliegue que preparan el código base para ser instalado en la plataforma y luego dependiendo del tipo de plataforma, la posibilidad de compartir la aplicación en un catalogo de aplicaciones creando un espacio de comercialización (marketplace). Esta rama comparte algunas de las características de utility computing como el manejo de recursos y cuotas la escalabilidad a demanda y agrega otras como el balanceo de carga y customización programática debido a que el grado de abstracción en el cual se trabaja es a nivel de aplicación y no a nivel de infraestructura.

Dentro de las compañías que construyeron este tipo de plataformas se encuentra Google Inc. (Google App Engine), Bungee Labs y otras.

Características resumidas

• Desarrollo de aplicaciones bajo una plataforma

• Escalable a demanda

• Proporciona balanceo de carga

• Maneja recursos

• La plataforma nuclea una comunidad de aplicaciones

• El desarrollo es soportado por herramientas de desarrollo, empaquetado y despliegue

• Estandarización del modelo de aplicación

• Conociendo el modelo se puede tratar a los componentes a discreción

• Se comparten características con el modelo base de Software como Servicio y Utility Computing

• SaaS y Software as Self Service

En tercer lugar aparece una categoría denominada software as self service. Esta rama no se encuentra definida en ningún lado sino que es mi propia aproximación a un conjunto de ofrecimientos relacionados con Software como Servicio con un fuerte ingrediente de auto servicio.

En un nivel de abstracción más alto que utility computing y platform as a service, software as self service nuclea aquellas aplicaciones que brindan cierta funcionalidad (CRM, ERP, procuración, recursos humanos, etc.) apuntando a empresas que buscan customizar la aplicación a sus propias necesidades. El tipo de funcionalidad abarca desde la customización del modelo de datos, la customización del comportamiento de la aplicación hasta la customización de flujos de trabajo.

Relacionado con el concepto de self service, el consumidor podría realizar todo esto por sí mismo con alguna aplicación de administración.

Características resumidas

• Customización de las aplicaciones

• Modelo de datos

• Flujos de trabajo

• Interfaz de usuario

• Herramientas para facilitarle el proceso de configuración al cliente (auto servicio)

• Extensión del modelo base de Software como Servicio

• SaaS y Software + Services

El término "Software + Services" fue concebido por Microsoft con el objetivo de ponerle un nombre a la estrategia relacionada con Software como Servicio. La categoría software + services aporta otras características que no son parte del modelo base, pero que agregan valor al modelo en general. La siguiente definición, extraída del sitio de Microsoft, resume el concepto:

"Software-plus-Services is an industry shift – combining Internet services with client and server software to deliver more compelling opportunities and solutions. Microsoft helps its customers and partners capitalize on the opportunities presented by the evolution to Software-plus-Services. Microsoft"s platform uniquely supports all classes of the services manifestation — services delivery (Saas), services composition (SOA) or the services experience (Web 2.0) — across a range of devices in addition to the PC, the various types of browser clients, servers in data-centers and Internet services." [Microsoft Corp., 2008] La combinación de servicios de internet con software cliente y de servidor como indica la definición y el acceso a través de diferentes dispositivos, no solamente la PC es la visión de Microsoft. En resumen, no solamente la experiencia web es importante, sino también la experiencia con dispositivos, la experiencia del escritorio y la experiencia sin conexión.

Características resumidas

• Visión de Microsoft

• Flexibilidad

• Mezcla de los dos mundos (internet y PC)

• Extiende la experiencia del usuario

• Web, Escritorio, Dispositivos

• Experiencia Offline

• Extensión del modelo base de SaaS

• SaaS y Service Oriented Architecture

"Service-oriented architecture (SOA) is a methodology for systems development and integration where functionality is grouped around business processes and packaged as interoperable services."9

Según la definición, SOA permite exponer funcionalidad empaquetado como servicios interoperables que permiten la integración. Es decir SOA agrega un ingrediente importante al modelo que está relacionado con la integración y la interoperabilidad con aplicaciones de terceras parte o propias. SOA entonces es un sub conjunto que agrega valor a una solución SaaS no solo en la integración a nivel funcional sino también a nivel seguridad con estándares como WS-Trust y WS- Federation.

Características resumidas

• SOA agrega valor a SaaS

• Permitiendo que la aplicación SaaS no se convierta en un silo

• Habilitando la composición de nuevas aplicaciones

• Permite pensar en un modelo de seguridad federado

• Sub conjunto del modelo base de SaaS

• Análisis del Mercado

A la fecha de realización de esta tesis la siguiente es una fotografía del mercado. Se relevaron las soluciones y productos más significativas y a partir de un análisis se las categorizó en su respectiva esfera. Las categorizaciones no son determinísticas y en ciertos casos existe un solapamiento.

Figura 15 – Taxonomía del mercado Luego de haber realizado un primer análisis de las diferentes ramas que influencian el Software como Servicio, en las siguientes secciones se estudiará con más detalle cada una de estas características.

• Capacidades intrínsecas del modelo

Existen un conjunto de características que pueden clasificarse como intrínsecas o base del modelo de Software como Servicio. El concepto de multi tenancy y la posible aislación de cada cliente, la experiencia del usuario, la monetización de la aplicación, el monitoreo y medición, el manejo de acuerdos de niveles de servicio, la disponibilidad de los datos y la administración delegada son algunas de las características que fueron mencionadas en la sección anterior.

• Multi tenancy y aislación

Una de las características arquitectónicas más asociadas a este modelo es multi tenancy. Este término se podría traducir como multiples inquilinos. Es decir, un mismo código base y/o infraestructura que sirva a múltiples clientes (tenants). Por ejemplo, en un contexto en el cual una aplicación bancaria es ofrecida como servicio por una empresa de la industria financiera, multi tenancy se refiere a la posibilidad de ofrecer el servicio a múltiples bancos compartiendo entre todos una única instancia de la aplicación bancaria.

Una aplicación puede ser diseñada para un único cliente, para múltiples clientes o para múltiples clientes y adicionalmente proveer la capacidad de customizar la instancia. El nivel de complejidad aumenta y el tiempo y costo posiblemente también. La siguiente tabla ilustra las diferencias en las diferentes etapas de un proyecto.

Durante el diseño y la construcción sería más costoso implementar la aplicación multi tenant pero en el largo plazo esto debería tener un retorno de la inversión (ROI) más alto a medida que se agreguen nuevos tenant durante la operación del sistema [Carraro, 2007].

Por otro lado, al compartir la misma instancia aparecen nuevos desafíos. Por ejemplo, si cierta empresa hace un uso intensivo del servicio, el proveedor puede querer, en primer lugar detectar esto y en segundo lugar tomar acciones. Estas acciones pueden ser aislarlo o moverlo a un cluster junto con otros tenants que no utilicen tantos recursos. Esta característica se denomina aislación. Otro desafío se manifiesta cuando el servicio ofrece capacidades relacionadas con customización. En este escenario, si la plataforma no tiene los mecanismos de protección necesarios el tenant podría realizar una customización que consuma considerables recursos, perjudicando a otros tenants.

• Experiencia del usuario

Otra característica de las aplicaciones ofrecidas como servicio es la usabilidad y la experiencia del usuario final. La web y el browser es un medio ubicuo hoy en día y el modelo Software como Servicio lo adopta como canal de distribución principal. La mayoría de los proveedores exponen su software al menos vía web.

En etapas iníciales del modelo, los proveedores ofrecían únicamente acceso por internet y via web, pero de a poco fueron incorporando capacidades offline y accesos via dispositivos móviles por la demanda de los consumidores.

En particular, Microsoft bajo su programa software más servicios pregona la importancia de combinar lo mejor de los dos mundos. Es decir, la composición de software local con servicios de internet interactuando entre sí.

• Esquemas de monetización, monitoreo y medición, manejo de SLA

Este grupo de características se define de la siguiente manera

• Cobrar por el uso de la aplicación

• Medir y monitorear el uso del servicio

• Manejar un acuerdo de nivel de servicio

Los esquemas de monetización más utilizados son: por subscripción, por utilización o basado en publicidad. Por ejemplo, Salesforce monetiza su aplicación de CRM cobrando una subscripción por usuario. Los servicios S3 o EC2 de Amazon se pagan por utilización, es decir solo se paga lo que se utiliza. Además, los servicios de Amazon varían su precio según si el cliente desea utilizar los datacenters europeos o estadounidenses. Por último, una manera menos ortodoxa de monetizar especialmente usada en servicios con importante tráfico, es la utilización de publicidad, en donde por cada impresión y/o click el proveedor cobra una comisión.

Cuando un proveedor elije cobrar por el servicio a sus clientes, estos esperan una determinada calidad de servicio. El proveedor comienza a manejar algún tipo de acuerdo de nivel de servicio, a monitorearlo, medirlo y reportarlo. Para esto se definen Service Level Objectives (SLO), que son objetivos de un determinado nivel de servicio para un recurso o un conjunto de recursos. Este puede ser expresado en unidades como tiempo de respuesta promedio o en función de la disponibilidad mensual de un cierto servicio. Un SLA debería estipular el pago y/o las penalidades asociadas al incumplimiento de un criterio acordado.

• Administración delegada

Otra de las características comunes del modelo es la delegación de la administración. El concepto de administración delegada proviene del uso de servicios de directorios para administrar usuarios y roles que es muy utilizado en grandes empresas multi departamentales.

Este concepto extrapolado a otras tareas administrativas se puede encontrar en aplicaciones de Software como Servicio. El cliente o tenant podría realizar tareas administrativas relacionadas a la aplicación utilizando alguna herramienta evitando al proveedor incurrir en costos de administración y agilizando las operaciones. Por ejemplo, si el tenant desea habilitar un nuevo usuario para que acceda a la aplicación, lo podría hacer desde un panel de control sin intervención del proveedor.

• Capacidades relacionadas con Service Oriented Architecture (SOA)

El software brindado como servicio es un modelo de negocios que puede o no incluir un estilo de arquitectura basado en servicios. Adoptar SOA puede ser una ventaja competitiva para el proveedor porque habilita escenarios de integración, mashups10 y automatización.

• Integración, mashups y automatización

La integración de aplicaciones representa la mayor preocupación en una encuesta realizada por Forrester. Más de un 60% alega que no está interesado en adoptar Software como Servicio porque no ve una clara estrategia de integración con su portfolio de aplicaciones [Forrester Research, 2008]. Por ejemplo, una empresa que desea crear un panel de control integrado de recursos humanos y mantiene su nómina de empleados en un sistema in-house y por otro lado contrata una aplicación de reclutamiento bajo el modelo SaaS se encuentra con el desafío de interactuar y agregar los datos de ambas aplicaciones. Si el proveedor que ofrece el servicio expusiese los servicios de la aplicación, el cliente podría consumirlos y crear el panel de control sin intervención del proveedor.

En una encuesta realizada en julio de 2008, se reveló que salesforce.com procesa por día 150 millones de transacciones y más de la mitad provienen de otras aplicaciones que no son nativas de Salesforce [ProgrammableWeb, 2006]. Esto demuestra la relevancia de proveer mecanismos que permitan al cliente integrar sus aplicaciones tradicionales con aquellas en "la nube".

No obstante, la exposición de los servicios puede ser una brecha de seguridad que violaría la confidencialidad de los datos del consumidor. Por tal razón, el proveedor debe pensar una estrategia para asegurar los servicios.

• Manejo de identidad y control de acceso federado

El manejo de identidad y la seguridad es otra de las preocupaciones de los consumidores, un 50% reveló esta preocupación según encuestas [Forrester Research, 2008]. En un análisis más detallado, las empresas ven un riesgo en tener usuarios con un perfil de negocio con poco entrenamiento, manejando los usuarios, roles y controles de acceso de la aplicación, caso que se da seguido en aplicaciones SaaS con administración delegada.

Una característica que hoy no está del todo explotada en Software como Servicio es el manejo federado de la identidad y los controles de acceso. Mediante soluciones de Identidad Federada11 los usuarios pueden emplear la misma identificación personal (típicamente usuario y contraseña) para identificarse en redes de diferentes departamentos o incluso empresas. De este modo las empresas comparten información sin compartir tecnologías de directorio, seguridad y autenticación, como requieren otras soluciones. Para su funcionamiento es necesaria la utilización de estándares que definan mecanismos que permiten a las empresas compartir información entre dominios. El modelo es aplicable a un grupo de empresas o a una gran empresa con numerosas delegaciones y se basa en el "círculo de confianza" de estas, un concepto que identifica que un determinado usuario es conocido en una comunidad determinada y tiene acceso a servicios específicos.

En el contexto de Software como Servicio, las empresas que formarían la federación son el consumidor y el proveedor. De esta manera, el personal de IT de la empresa que consume el servicio manejaría un único repositorio de usuarios y roles.

• Capacidades relacionadas con utility computing y platform as a service

En el año 2006, la aplicación SmugMug que ofrece un servicio de almacenamiento de fotos, publicó el ahorro logrado al utilizar Amazon S3 para almacenar y servir los 193TB de fotos de sus usuarios. Por año ahorrarían 692.000 dólares entre costos de discos y personal y aumentarían la disponibilidad de su aplicación al confiar en el servicio de Amazon [Amazon.com, 2006].

Los proveedores que se aventuran en la construcción de una aplicación de Software como Servicio pueden decidir utilizar recursos ubicuos no sólo como una alternativa que reduce costos operativos, de hardware y hasta infraestructura edilicia sino que también como parte del núcleo de su arquitectura y estrategia de escalabilidad y disponibilidad.

Como toda innovación, requiere de tiempo para que sea adoptada por compañías que tienen un departamento de IT establecido. Sin embargo, podrían encontrar usos a estos servicios en casos donde se requiera de poder computacional y almacenamiento a escala. Un ejemplo de esto es el diario New York Times que utilizó Amazon EC2 y S3 para procesar 11 millones de artículos de diarios desde 1851 a 1922 convirtiéndolos a PDF en sólo un día [Gottfrid, 2007].

A continuación se detallan las características más significativas de este tipo de servicios.

• Recursos computacionales

Los recursos computacionales a demanda incluyen capacidades de almacenamiento de datos, de archivos, poder de procesamiento y ancho de banda.

En el almacenamiento de datos, Google BigTable es un ejemplo de una base de datos (basada en tablas de hash distribuidas) y Microsoft SQL Server Data Services es una base de datos más orientada al modelo relacional. Ambas son manejadas y provistas como servicios por sus correspondientes proveedores y permiten al consumidor guardar y extraer datos utilizando un lenguaje de consulta.

En segundo lugar se encuentra el almacenamiento de archivos y el ancho de banda. El proveedor ofrece capacidad de almacenamiento virtualmente infinito, cobrando por el espacio utilizado y por el ancho de banda. El ejemplo más conocido es Amazon S3 que ofrece espacio de almacenamiento que es manejado mediante una API de webservices. Las content delivery networks (CDN) también podrían entrar en esta categoría, con la salvación de que este servicio está orientado a imágenes solamente.

Otro de los recursos disponibles es el poder de procesamiento. Los proveedores que ofrecen este servicio utilizan la virtualización y permiten crear un número arbitrario de máquinas virtuales en donde el usuario tiene la libertad de manejarlas.

• Platform as a service

Platform as a service puede verse como una especialización de utility computing en donde se añaden servicios de valor agregado sobre la infraestructura base. Es decir, son servicios ubicados en una capa de abstracción más alta que permite no solamente utilizar recursos computacionales sino también desarrollar y desplegar aplicaciones sobre esos recursos y entregar recursos de plataforma. Similar a un application server pero disponible en la red y con capacidades pensadas para el desarrollo de aplicaciones de Software como Servicio. Este tipo de plataformas cuentan con herramientas de empaquetado de aplicaciones, scripts, SDK y hasta un ambiente de desarrollo offline. Google App Engine es un ejemplo de un proveedor de plataforma de aplicaciones que expone la masividad de los recursos de Google para desarrollar utilizando Python como lenguaje de programación y expone una API para brindar almacenamiento en BigTable.

Las plataformas pueden ofrecer la publicación de la aplicación en un catálogo y así exponer la aplicación aprovechando la base de usuarios de la plataforma. Esto es lo que hacen plataformas como Facebook o Salesforce AppExchange.

Otra característica que puede ofrecer este tipo de plataformas es el balanceo de carga, que se define como la capacidad de distribuir la carga entre instancias de servidores de aplicación.

Relacionado con el aprovisionamiento automático de instancias y la escalabilidad a demanda, la característica de balancear la carga automáticamente entre los servidores permite hacer un mejor uso de los recursos en una aplicación expuesta públicamente en internet.

Las compañías con cierto volumen de aplicaciones pueden explorar el concepto de plataforma de aplicaciones en el contexto de una estrategia corporativa, automatizando y estandarizando su portfolio de aplicaciones y aprovechando la cantidad de recursos computacionales disponibles. Este concepto se conoce también como private cloud o IntraSaaS.

• Escalabilidad a demanda

La escalabilidad a demanda se define como la capacidad de aumentar o disminuir los recursos a medida que el consumidor lo requiera. Esto aplica a todo tipo de servicio que pueda escalar horizontalmente como almacenamiento, poder de procesamiento e instancias de servidores web y representa una típica característica ofrecida en este tipo de servicios.

• Aprovisionamiento automático y Manejo de quota y recursos

Una de las características fundamentales de utility computing es la automatización del proceso de aprovisionamiento del servicio. El servicio no escalaría si habría una intervención humana por cada nueva instancia a crear. El proceso de aprovisionamiento será un conjunto de pasos estipulados o un workflow en el cual se crearán, según el Acuerdo de Nivel de Servicio (SLA) establecido por el servicio seleccionado y los recursos disponibles, las instancias necesarias.

El aprovisionamiento está relacionado con el manejo de recursos y quotas. Es decir, la arquitectura de este servicio debe contemplar el manejo de recursos y sus respectivos límites.

Por ejemplo, un tenant contrata una aplicación para manejo de proyectos bajo el modelo Software como Servicio. El proveedor aprueba la orden y lanza el aprovisionamiento del cliente. El servicio de aprovisionamiento puede decidir ubicar al tenant en un servidor web "Y" porque el servidor "X" no tiene recursos disponibles (la cantidad de recursos llegó al límite).

Otro caso sería un tenant utilizando una plataforma de aplicaciones que según el SLA soporta una cantidad X de requests por día (quota). El tenant podría pedir un aumento de la quota y el proveedor aprovisionar un nuevo servidor web y un balanceador de carga que aumente a 2X la cantidad de requests por día.

En resumen, las características básicas de utility computing son el manejo de quotas y recursos, el aprovisionamiento automático y la escalabilidad a demanda. Combinando estas capacidades se logra el manejo de recursos computacionales (Infrastructure as a Service) o recursos de plataforma (Platform as a Service) como ilustra la siguiente figura.

Figura 16 – Características de utility computing

• Capacidades relacionadas con customización y configuración

Diferentes tipos de aplicaciones requieren diferentes niveles de configuración y customización. Un ejemplo cotidiano son las aplicaciones de escritorio, como ser hojas de cálculo o procesadores de texto, que son configuradas por el usuario final generalmente utilizando menús y wizards. Por otro lado, aplicaciones más complejas como Enterprise Resource Planning (ERP) o Customer Relationship Management (CRM) requieren compañías integradoras o desarrolladores que escriban el código específico para las necesidades de la empresa.

La posibilidad de configurar y customizar una aplicación de software está relacionada con el concepto de Software Product Lines o Líneas de Producto [Kang K., 1990]. El objetivo de Líneas de Productos de software es identificar oportunidades de reusabilidad en una línea de producto. Para eso identifica las responsabilidades del sistema que resuelven los requerimientos funcionales comunes y a su vez la variabilidad del dominio en cuestión. La diferencia radica en que en el caso de SPL esto ocurre en las etapas de diseño y construcción y en Software como Servicio ocurre en tiempo de ejecución. Es decir el usuario del sistema es el que decide la variabilidad utilizando herramientas de configuración y el proveedor es el que brinda la plataforma para que eso suceda.

En este escenario es fundamental acotar el espectro de configurabilidad a un conjunto que permita mantener los acuerdos de nivel de servicio sin poner en riesgo a otros tenants. Ligado a esto se definen capacidades como nivel de aislación del tenant.

El primer paso para lograr un sistema configurable es que el proveedor tenga herramientas para manejar la variabilidad de cada tenant. Una vez que detectadas las bifurcaciones del sistema original con cada instancia se puede comenzar a explorar la exposición de herramientas de auto servicio para transferirle la autoridad al tenant.

Los cuatro grupos de capacidades principales son customización visual, customización del comportamiento, customización del modelo de datos y configuración autoservicio.

• Customización del modelo de datos

La capacidad de extender el modelo de datos se compone de dos características:

• Poder agregar nuevas columnas a una entidad del modelo

• Poder agregar nuevas entidades

En la primera se trata de extender una o varias entidades de la definición base del modelo de datos con nuevos campos. Por ejemplo, un catálogo de productos que posee la entidad Producto posee los atributos base: nombre y precio. Sin embargo, cierta empresa que comercializa fertilizantes está interesada en incluir en la definición de producto un campo que indique si se trata de un fertilizante orgánico o no y además quiere incluir el costo de producción.

La segunda característica puede ser más compleja ya que la variabilidad es más importante. Siguiendo el ejemplo del fertilizante, a la empresa podría interesarle almacenar el químico principal que compone a cada fertilizante. Para eso deben introducir una nueva entidad Componente y extender la entidad Producto con un campo de referencia a Componente.

Salesforce.com provee esta característica a sus clientes y de hecho han patentado el mecanismo de extensibilidad que utilizaron [Weissman y otros, 2005].

• Customización del comportamiento

La capacidad de extender el comportamiento de una aplicación se compone de tres características:

• Poder reemplazar funcionalidad por implementaciones específicas para un tenant

• Poder modificar los flujos de trabajo

La modificación de ciertos servicios está relacionada con estrategias, reglas de negocio o algoritmos específicos del dominio de la aplicación. Por ejemplo, en un sistema de cálculo de salarios el algoritmo de cálculo podría diferirse según el país donde opera el cliente. El objetivo es que el proveedor en primera instancia pueda modificar estas reglas sin tener que modificar gran parte de la aplicación y en segunda instancia exponer al tenant esta capacidad promoviendo el self-service.

La modificación de flujos de trabajo apunta primero a poder definir los flujos de trabajo de la aplicación en cuestión y luego a identificar la variabilidad y habilitar la extensibilidad necesaria para poder realizar las modificaciones a la instancia del tenant. Dentro de esta característica se encuentra la posibilidad de modificar expresiones que definan una decisión dentro del workflow. Un ejemplo podría ser la expresión "si el monto de la compra es mayor a X", donde X y monto de compra son configurables (if compra.monto > X).

Un segundo nivel de variabilidad se manifiesta en la posibilidad de agregar actividades en medio de un flujo de trabajo en lugares preestablecidos por el proveedor. Como ejemplo de este caso se podría pensar en el deseo de un tenant de enviar un email a todos los participantes de la compra una vez que se decidió el monto de compra y esta fue ejecutada. Otro ejemplo más complejo podría incluir la llamada a un webservice y así permitir al tenant realizar lo que desee mientras cumpla con el contrato del servicio.

La modificación de flujos de trabajo podría ser expuesta al tenant y así aplicar a esta característica la capacidad de self-service. Sin embargo si el proveedor desea que esto ocurra, debe manejarse con extremo cuidado y proteger a los demás tenants de las modificaciones que puedan perjudicarlos.

• Customización visual

La capacidad de modificar la apariencia o la presentación de la aplicación se basa en las siguientes características:

• Poder modificar la manera en que se visualiza una entidad

• Poder customizar el estilo de la aplicación

• Poder customizar el layout de la aplicación

• Poder customizar los mensajes e imágenes

El concepto de customización visual está relacionado con white labeling12 que se utiliza en marketing haciendo alusión a un producto o servicio producido por una compañía (productora) que es remaracado por otra compañía (comercializadora) simulando que fue de su propia producción.

La customización del estilo y layout permite dar una identidad visual a la aplicación que se alinee a los estándares de la empresa que utiliza el servicio. Como ejemplo se puede citar una plataforma de blogging, donde la empresa no quiere utilizar el formato default sino que quiere modificarlo con el objetivo de difundir su propia identidad no solo mediante el contenido sino también la forma en que se ve.

Tanto el estilo como el layout son customizaciones ubicadas en un primer nivel de dificultad y aplicable a un espectro mayor de aplicaciones. Más ligado a las aplicaciones de negocio y a la característica de extensión del modelo está la customización visual de una entidad y de tipo de datos. Por ejemplo, un tenant desea ordenar y agrupar los campos de cierta entidad con el objetivo de mantener una disposición similar a la que los operadores estaban acostumbrados en el sistema anterior. Otro tipo de customización más avanzada podría ser visualizar un campo de texto que guarda una georeferencia con un control de mapa.

Otra característica relacionada con la visualización es la capacidad de modificar los mensajes o imágenes de acuerdo a ciertos parámetros. Un claro ejemplo es poner el logo de la empresa o definir mensajes según el segmento al cual pertenece el cliente.

Resumiendo esta sección, la siguiente figura muestra los atributos principales relacionados con configuración y customización. En el medio aparece el concepto de self service que es una característica opcional aplicable a estos tres atributos que habilita al tenant a que customize por sus propios medios.